An operating system (OS) includes a kernel (core kernel) that controls basic management of a CPU (Central Processing Unit) or a main memory, and a daemon that provides various services to a user or an application.
FIG. 11 is a conceptual view illustrating an internal configuration of a conventional OS and a state where kernel modules and daemons are acquired from a boot disk. Throughout the drawings, the same reference numerals are used to designate the same or corresponding component parts, and redundant descriptions are omitted. A computer 19 illustrated in FIG. 11 includes a CPU 20 as a processor, a memory 21 as a main memory, and a boot disk 22. The memory 21 includes an OS 23 loaded from the boot disk 22. The OS 23 includes a kernel 24 and daemons 25. The kernel 24 includes kernel modules 26.
The CPU 20 executes all processing performed on the computer 19. The memory 21 is a volatile storage device. The boot disk 22 contains a program to be loaded on the memory 21 and is, e.g., a HDD. The kernel module 26 is a module program constituting the kernel 24.
As illustrated in FIG. 11, the kernel 24 has a module structure. That is, the kernel 24 is provided on the boot disk not as one binary object, but the kernel modules 26 and daemons 25 which are main components of the OS 23 are loaded from the boot disk 22 at the boot time of the OS 23 and thereby a kernel image is gradually expanded on the memory 21. Similarly, after the boot of the OS 23, the kernel modules 26 and daemons 25 are incorporated in the kernel 24 according to requirement from a system.
The kernel module 26 is, e.g., a device driver. The device driver is a component that controls an I/O device such as a disk and a tape device. The device driver is resident in the kernel and controls the interface between a device and kernel. The device driver is implemented in the kernel as a dynamically loadable module and is provided as an individual binary file for each device type. The device driver is automatically loaded at the initial access time to a corresponding device.
The kernel 24 provides a logical path for enabling a user to access to a disk in addition to a physical path indicating a physical disk position and manages the logical and physical paths in association with each other. This is because, in the case where a user handles a physical device such as a disk, the physical path of the device is not directly specified, but the physical path needs to be converted to the logical path for easy handling of the OS.
In order for the OS 23 to be booted, a not illustrated firmware expands the program of the OS 23 stored in the boot disk 22 onto the memory 21, and processing runs according to a procedure written in the program. The kernel 24 is booted first, followed by start-up of the services of the daemons 25.
Hereinafter, details of OS boot processing (kernel initialization) in a conventional OS boot system will be described.
FIG. 12 is a block diagram illustrating an example of a configuration of a computer in a conventional OS boot system. FIG. 13 is a conceptual view of a tree structure of a root file system constituting a boot disk. A computer 19 illustrated in FIG. 12 includes a CPU 20, an OBP (Open Boot Program) 27, a boot disk 22, a memory 21, and an external storage device 28. The memory 21 includes a ufsboot 29, a core kernel 30, and a storage device driver 31 which are expanded by programs to be described later.
The OBP 27 is a ROM that is booted first at power-on time, in which a firmware program that performs OS boot processing is recorded. The external storage device 28 is a storage device, such as a tape drive, in which backup data of the boot disk 22 has been stored as a hedge against a failure of the boot disk 22.
The ufsboot 29 is a boot program. The core kernel 30 performs incorporation of the kernel module or daemon as initialization of the kernel. The storage device driver 31 is a driver for the storage device. The above three programs are stored in the boot disk 22.
The boot disk 22 has a file structure created in a tree form called “root file system” as illustrated in FIG. 13 for reading/writing of recorded information. This file structure is represented as a tree having a single root node called “root (/)”. By connecting the logical path of the boot disk 22 and root (/) of the root file system using a mount command provided by the OS, access to files recorded on the boot disk 22 is made possible. The above association is called “mount”.
Next, operation of kernel initialization in the conventional OS boot system will be described.
FIG. 14 is a flowchart of the OS boot processing of the computer in the conventional OS boot system. All the processing involved in the OS boot, including the following program execution processing of the OBP, are executed by the CPU 20. First, when power of the computer 19 is turned on by a user (S101), the OBP 27 starts an automatic boot process to recognize a hardware configuration and creates a device tree as illustrated in FIG. 13 (S102). The device tree is physical device configuration information.
After creating the device tree, the OBP 27 issues an OS boot instruction (S103) and expands a boot block stored in the beginning of the boot disk 22 on the memory 21 (S104). The storage location of the ufsboot 29 which is a boot program stored in the root file system constructed on the boot disk 22 has been written in the boot block. The OBP 27 reads the ufsboot 29 with reference to the written storage location and loads the ufsboot 29 onto the memory 21 (S105). The loaded ufsboot 29 boots the core kernel 30 (S106) and transfers control to the core kernel 30 (S107).
As illustrated in FIG. 13, after the transfer of the control to the core kernel 30, the core kernel 30 mounts (/=/devices/pci@17, 4000/scsi@3/sd@1, 0:b), in a read-only attribute, a physical path (/devices/pci@17, 4000/scsi@3/sd@1, 0:b) which has been given from the ufsboot 29 for enabling access to the boot disk 22 as a physical device and the root (/) of the root file system. After the mount of the physical path and root of the root file system, the core kernel 30 searches the root file system for a kernel module required for the kernel initialization, loads the found kernel module onto the memory 21, and starts the kernel initialization processing (S108). After the start of the kernel initialization processing, the core kernel 30 associates the logical path for the OS to access the boot disk 22 as a logical device with the physical path of the boot disk 22 (S109), whereby the load of the kernel is completed (S110).
FIG. 15 is a table representing a correspondence between the physical path and logical path of the boot disk in the conventional OS boot system. As illustrated in FIG. 15, the core kernel 30 associates the physical path (/devices/pci@17, 4000/scsi@3/sd@1, 0:b) and logical path (/dev/dsk/c1t0d0) of the boot disk 22 to thereby create the correspondence table. The core kernel 30 receives a given logical path from a user at access time and refers to the correspondence table to determine to which physical device specified by a physical path a logical device specified by the logical path corresponds.
As illustrated in FIG. 14, after the association between the logical and physical paths, the core kernel 30 refers to the disk mount correspondence table (/→/dev/dsk/c1t0d0) previously retained in the boot disk 22 to remount (/=/dev/dsk/c1t0d0), in a readable/writable attribute, the logical path (/dev/dsk/c1t0d0) of the boot disk on the root (/) of the root file system, as illustrated in FIG. 13 (S111). The above mount allows access to a file stored on the boot disk 22, whereby the kernel initialization processing is completed (S112).
The kernel module incorporates a component required by the system even after the boot of the OS in the kernel as needed, so that the access to the boot disk needs to be guaranteed at all times, and unmount of the root file system cannot be made until the system is stopped (only the attribute representing availability of reading/writing can be changed). The unmount is to eliminate the mount and, more specifically, to release association between the paths established by the mount using an unmount command provided by the OS.
The kernel initialization is achieved by the above processing. Meanwhile, a backup system as described below is prepared in the computer for a failure of the OS boot disk.
FIG. 16 is a conceptual view of a conventional boot disk backup system. As illustrated in FIG. 16, the core kernel 30 loads the storage device driver 31 stored in the boot disk 22 onto the memory 21 to activate the storage device driver 31 to thereby recognize the external storage device 28 and then copies data of the boot disk 22 to the external storage device 28. With the above processing, backup data of the boot disk 22 is stored in the external storage device 28 as a hedge against a failure of the boot disk 22.
In the case where the backed up data of the boot disk is written back, the boot disk itself that has booted the system is subjected to overwrite, so that it is necessary to boot the OS from another system disk. Generally, a method is taken in which backup data is written back to the boot disk after the system is booted from a read-only OS medium, such as a CD-ROM. In this case, in the OS boot system, the OS medium takes the place of the boot disk, and the kernel initialization can be achieved by the same processing as that illustrated in the flowchart of FIG. 4.
There is known a method and a system that create an OS having selected functions for use as a conventional art relating to the present invention. [Patent Document 1] Japanese Laid-open Patent Publication No. 2003-099268
In the case where the backup data is written back, the write-back operation needs to be performed after the core kernel is made to recognize the external storage device in which the backup data has been stored at system boot time. However, in the case where the storage device driver functioning as a program for driving the external storage device is not recorded in the OS medium such as a CD-ROM, the core kernel cannot recognize the external storage device, disabling the write-back of the backup data. To solve this problem, it is necessary to temporarily replace the OS medium with a medium containing the driver of the storage device after the system has been booted from the OS medium. However, the OS medium is in a mount state, so that unmount of the file system of the OS medium cannot be made, making it impossible to perform replacement of the OS medium and storage device driver.
FIG. 17 is a conceptual view of boot disk restoration in the conventional OS boot system using CD-ROM medium. As illustrated in FIG. 17, it is impossible to eject an OS medium 33 during operation of the OS. Further, the OS medium 33 is present in a CD-ROM drive 32 and therefore a storage device driver medium 34 cannot be set. As a result, a storage device driver 31 cannot be read, and the restoration of the boot disk 22 cannot be performed.